Record 1.0.0 as shipped and verified - #65
Merged
Merged
Conversation
The install-side verification list was walked in full for 1.0.0 — signtool on each MSI, install, upgrade and uninstall per scope, .wboard by double-click, both channels side by side, and SmartScreen on a clean machine. It was the last part of the chain that had only ever been reasoned about, so release-management.md no longer describes it as never done, and the TODO section that asked for it before promotion is gone. The Store listing is on 1.0.0. Certification now runs unattended in under an hour rather than the hours to days it took when decision 13 was written, which changes how long the Store lags the download rather than the reasoning: it is still someone else's queue and still must not gate a release that is already built and signed. Decision 13 says so directly rather than resting on a timing that has since moved. STORE-LISTING.md and the site verification script join installer/winget in the pipeline's exclude list. Neither is read by a build, and the exclusion is there so a change to distribution metadata cannot publish a pre-release byte-identical to the one before it. Only the one markdown file, since the rest of installer/msix is the package manifest and its assets. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything here follows from 1.0.0 actually shipping.
The install-side verification was walked in full for 1.0.0 —
signtool verifyon eachMSI, install/upgrade/uninstall per scope,
.wboardby double-click, both channels side byside, SmartScreen on a clean machine.
release-management.mddescribed that list as whathad not been done for a real release, which is no longer true; it now records that it
was walked, and says the part worth keeping — that the list is what exercises installer
authoring, and nothing before it installs the result. The
TODO.mdsection asking for itbefore promotion is gone.
The Store listing is on 1.0.0, and certification now runs unattended in under an hour
rather than the hours to days it took when decision 13 was written. That changes how long
the Store lags the download, not the reasoning, so decision 13 now rests on what is
actually load-bearing: it is someone else's queue, it can stall or reject, and none of
that may hold up a release already built and signed. The old wording justified the
decision entirely by a timing that has since moved.
One pipeline change.
installer/msix/STORE-LISTING.mdwas not excluded from theAzure trigger, so editing listing text published a signed pre-release byte-identical to
the one before it — exactly what the existing
installer/wingetexclusion exists toprevent, with the same rationale already written beside it. It is excluded as a single
file rather than the folder, because the rest of
installer/msixis the package manifestand its assets, which do go into a build.
scripts/verify-published-site.ps1joins it forthe same reason: it runs in the Pages deployment and never in a build.
Note that merging this still triggers one Azure run, because
.azure/is itself notexcluded and this touches the pipeline file. That is the last one; later edits to the
listing text will not.
🤖 Generated with Claude Code